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A Framework for Large-Scale Measurement of Broadband Performance (LMAP) 
Abstract 


Measuring broadband service on a large scale requires a description 
of the logical architecture and standardisation of the key protocols 


that coordinate interactions between the components. This document 
presents an overall framework for large-scale measurements. It also 
defines terminology for LMAP (Large-Scale Measurement of Broadband 
Performance). 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7594. 
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1. Introduction 


There is a desire to be able to coordinate the execution of broadband 
measurements and the collection of measurement results across a large 
scale set of Measurement Agents (MAs). These MAs could be 
software-based agents on PCs, embedded agents in consumer devices 
(such as TVs or gaming consoles), embedded in service-provider- 
controlled devices such as set-top boxes and home gateways, or simply 
dedicated probes. MAs may also be embedded on a device that is part 
of an ISP's network, such as a DSLAM (Digital Subscriber Line Access 
Multiplexer), router, Carrier Grade NAT (Network Address Translator), 
or ISP Gateway. It is expected that a measurement system could 
easily encompass a few hundred thousand or even millions of such MAs. 
Such a scale presents unique problems in coordination, execution, and 
measurement result collection. Several use Cases have been proposed 
for large-scale measurements including: 
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o Operators: to help plan their network and identify faults 


o Regulators: to benchmark several network operators and support 
public policy development 


Further details of the use cases Can be found in [RFC7536]. The LMAP 
framework should be useful for these, as well as other use Cases, 
such as to help end users run diagnostic checks like a network speed 
test. 


The LMAP framework has three basic elements: Measurement Agents, 
Controllers, and Collectors. 


Measurement Agents (MAs) initiate the actual measurements, which are 
called Measurement Tasks in the LMAP terminology. In principle, 
there are no restrictions on the type of device in which the MA 
function resides. 


The Controller instructs one or more MAs and communicates the set of 
Measurement Tasks an MA should perform and when. For example, it may 
instruct an MA at a home gateway: "Measure the ’UDP latency’ with 
www.example.org; repeat every hour at xx.05". The Controller also 
manages an MA by instructing it on how to report the Measurement 
Results, for example: "Report results once a day in a batch at 4am". 
We refer to these as the Measurement Schedule and Report Schedule. 


The Collector accepts Reports from the MAs with the Results from 
their Measurement Tasks. Therefore, the MA is a device that gets 
Instructions from the Controller, initiates the Measurement Tasks, 
and reports to the Collector. The communications between these three 
LMAP functions are structured according to a Control Protocol anda 
Report Protocol. 


The design goals are the following large-scale Measurement System 
features: 


o Standardised - in terms of the Measurement Tasks that they 
perform, the components, the data models, and the protocols for 
transferring information between the components. Amongst other 
things, standardisation enables meaningful comparisons of 
measurements made of the same Metric at different times and 
places, and provides the operator of a Measurement System with 
criteria for evaluation of the different solutions that can be 
used for various purposes including buying decisions (such as 
buying the various components from different vendors). Today’s 
systems are proprietary in some or all of these aspects. 
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o Large-scale - [RFC7536] envisages Measurement Agents in every home 
gateway and edge device such as set-top boxes and tablet 
computers, and located throughout the Internet as well [RFC7398]. 
It is expected that a Measurement System could easily encompass a 
few hundred thousand or even millions of Measurement Agents. 
Existing systems have up to a few thousand MAs (without judging 
how much further they could scale). 


o Diversity - a Measurement System should handle Measurement Agents 
from different vendors that are in wired and wireless networks, 
can execute different sorts of Measurement Tasks, are on devices 
with IPv4 or IPv6 addresses, and so on. 


o Privacy Respecting - the protocols and procedures should respect 
the sensitive information of all those involved in measurements. 


Outline of an LMAP-Based Measurement System 


In this section, we provide an overview of the whole Measurement 
System. New LMAP-specific terms are capitalised; Section 3 provides 
a terminology section with a compilation of all the LMAP terms and 
their definitions. Section 4 onwards considers the LMAP components 
in more detail. 


Other LMAP specifications will define an Information Model, the 
associated Data Models, and select/extend one or more protocols for 
the secure communication: firstly, a Control Protocol, for a 
Controller to instruct Measurement Agents regarding which performance 
Metrics to measure, when to measure them, and how/when to report the 
measurement results to a Collector; secondly, a Report Protocol, for 
a Measurement Agent to report the results to the Collector. 


Figure 1 shows the main components of a Measurement System, and the 
interactions of those components. Some of the components are outside 
the scope of initial LMAP work. 


The MA performs Measurement Tasks. One possibility is that the MA 
observes existing traffic. Another possibility is for the MA to 
generate (or receive) traffic specially created for the purpose and 
measure some Metric associated with its transfer. Figure 1 includes 
both possibilities (in practice, it may be more usual for an MA to do 
one) whilst Section 6.4 shows some examples of possible arrangements 
of the components. 


The MAs are pieces of code that can be executed in specialised 
hardware (hardware probe) or on a general-purpose device (like a PC 
or mobile phone). A device with a Measurement Agent may have 
multiple physical interfaces (Wi-Fi, Ethernet, DSL (Digital 
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Subscriber Line); and non-physical interfaces such as PPPoE 
(Point-to-Point Protocol over Ethernet) or IPsec) and the Measurement 
Tasks may specify any one of these. 


The Controller manages an MA through use of the Control Protocol, 
which transfers the Instruction to the MA. This describes the 
Measurement Tasks the MA should perform and when. For example the 
Controller may instruct an MA at a home gateway: "Count the number of 
TCP SYN packets observed in a 1 minute interval; repeat every hour at 
xx.05 + Unif[0,180] seconds". The Measurement Schedule determines 
when the Measurement Tasks are executed. The Controller also manages 
an MA by instructing it on how to report the Measurement Results, for 
example: "Report results once a day in a batch at 4am + Unif[0,180] 
seconds; if the end user is active then delay the report 5 minutes." 
The Report Schedule determines when the Reports are uploaded to the 
Collector. The Measurement Schedule and Report Schedule can define 
one-off (non-recurring) actions (for example, "Do measurement now", 
"Report as soon as possible"), as well as recurring ones. 


The Collector accepts a Report from an MA with the Measurement 
Results from its Measurement Tasks. It then provides the Results to 
a repository. 


A Measurement Method defines how to measure a Metric of interest. It 
is very useful to standardise Measurement Methods, so that it is 
meaningful to compare measurements of the same Metric made at 
different times and places. It is also useful to define a registry 
for commonly used Metrics [IPPM-REG] so that a Metric and its 
associated Measurement Method can be referred to simply by its 
identifier in the registry. The registry will hopefully be 
referenced by other standards organisations. The Measurement Methods 
may be defined by the IETF, locally, or by some other standards body. 


Broadly speaking there are two types of Measurement Methods. In both 
types, a Measurement Agent measures a particular Observed Traffic 
Flow. It may involve a single MA simply observing existing traffic 
-- for example, the Measurement Agent could count bytes or calculate 
the average loss for a particular flow. On the other hand, a 
Measurement Method may observe traffic created specifically for the 
purpose of measurement. This requires multiple network entities, 
which perform different roles. For example, to measure the round 
trip delay one possible Measurement Method would consist of an MA 
sending an ICMP (Internet Control Message Protocol) ECHO request 
("ping") to a responder in the Internet. In LMAP terms, the 
responder is termed a Measurement Peer (MP), meaning that it helps 
the MA but is not managed by the Controller. Other Measurement 
Methods involve a second MA, with the Controller instructing the MAs 
in a coordinated manner. Traffic generated specifically as part of 
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the Measurement Method is termed Measurement Traffic; in the ping 
example, it is the ICMP ECHO Requests and Replies. The protocols 
used for the Measurement Traffic are out of the scope of initial LMAP 
work and fall within the scope of other IETF WGs such as IPPM (IP 
Performance Metrics). 


A Measurement Task is the action performed by a particular MA at a 
particular time, as the specific instance of its role in a 
Measurement Method. LMAP is mainly concerned with Measurement Tasks, 
for instance in terms of its Information Model and Protocols. 


For Measurement Results to be truly comparable, as might be required 
by a regulator, not only do the same Measurement Methods need to be 
used to assess Metrics, but also the set of Measurement Tasks should 
follow a similar Measurement Schedule and be of similar number. The 
details of such a characterisation plan are beyond the scope of IETF 
work, although it is certainly facilitated by the IETF’s work. 


Both control and report messages are transferred over a secure 
Channel. A Control Channel is between the Controller and an MA; the 
Control Protocol delivers Instruction Messages to the MA and 
Capabilities, Failure, and Logging Information in the reverse 
direction. A Report Channel is between an MA and Collector, and the 
Report Protocol delivers Reports to the Collector. 


Finally, we introduce several components that are outside the scope 
of initial LMAP work that will be provided through existing protocols 
or applications. They affect how the Measurement System uses the 
Measurement Results and how it decides what set of Measurement Tasks 
to perform. As shown in Figure 1, these components are: the 
bootstrapper, Subscriber parameter database, data analysis tools, and 
Results repository. 


The MA needs to be bootstrapped with initial details about its 
Controller, including authentication credentials. The LMAP work 
considers the Bootstrap process, since it affects the Information 
Model. However, LMAP does not define a Bootstrap protocol, since it 
is likely to be technology specific and could be defined by the 
Broadband Forum, CableLabs, or IEEE depending on the device. 
Possible protocols are SNMP (Simple Network Management Protocol), 
NETCONF (Network Configuration Protocol), or (for Home Gateways) CPE 
WAN Management Protocol (CWMP) from the Auto Configuration Server 
(ACS) (as specified in TR-069 [TR-069]). 


A Subscriber parameter database contains information about the line, 
such as the customer’s broadband contract (perhaps 2, 40, or 80 
Mb/s), the line technology (DSL or fibre), the time zone in which the 
MA is located, and the type of home gateway and MA. These parameters 
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are already gathered and stored by existing operations systems. They 
may affect the choice of what Measurement Tasks to run and how to 
interpret the Measurement Results. For example, a download test 
suitable for a line with an 80 Mb/s contract may overwhelm a 2 Mb/s 
line. 


A Results repository records all Measurement Results in an equivalent 
form, for example an SQL (Structured Query Language) database, so 
that they can easily be accessed by the data analysis tools. 


The data analysis tools receive the results from the Collector or via 
the Results repository. They might visualise the data or identify 
which component or link is likely to be the cause of a fault or 
degradation. This information could help the Controller decide what 
follow-up Measurement Task to perform in order to diagnose a fault. 
The data analysis tools also need to understand the Subscriber’s 
service information, for example, the broadband contract. 
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MP: Measurement Peer 
Figure 1: Schematic of main elements of an LMAP-based Measurement 
System (showing the elements in and out of the scope of initial LMAP 
work) 


3. Terminology 


This section defines terminology for LMAP. Please note that defined 
terms are capitalised throughout. 
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Bootstrap: A process that integrates a Measurement Agent into a 
Measurement System. 


Capabilities: Information about the performance measurement 
capabilities of the MA, in particular the Measurement Method roles 
and measurement protocol roles that it can perform, and the device 
hosting the MA, for example its interface type and speed, but not 
dynamic information. 


Channel: A bidirectional logical connection that is defined by a 
specific Controller and MA, or Collector and MA, plus associated 
security. 


Collector: A function that receives a Report from an MA. 


Configuration: A process for informing the MA about its MA-ID, 
(optional) Group-ID, and Control Channel. 


Controller: A function that provides a Measurement Agent with its 
Instruction. 


Control Channel: A Channel between a Controller and an MA over which 
Instruction Messages and Capabilities, Failure, and Logging 
Information are sent. 


Control Protocol: The protocol delivering Instruction(s) from a 
Controller to a Measurement Agent. It also delivers Capabilities, 
Failure, and Logging Information from the Measurement Agent to the 
Controller. It can also be used to update the MA’s Configuration. 
It runs over the Control Channel. 


Cycle-ID: A tag that is sent by the Controller in an Instruction and 
echoed by the MA in its Report. The same Cycle-ID is used by several 
MAs that use the same Measurement Method for a Metric with the same 
Input Parameters. Hence, the Cycle-ID allows the Collector to easily 
identify Measurement Results that should be comparable. 


Data Model: The implementation of an Information Model in a 
particular data modelling language [RFC3444]. 


Environmental Constraint: A parameter that is measured as part of the 
Measurement Task, its value determining whether the rest of the 
Measurement Task proceeds. 


Failure Information: Information about the MA’s failure to take 


action or execute an Instruction, whether concerning Measurement 
Tasks or Reporting. 
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Group-ID: An identifier of a group of MAs. 


Information Model: The protocol-neutral definition of the semantics 
of the Instructions, the Report, the status of the different elements 
of the Measurement System, as well of the events in the system 
[RFC3444]. 


Input Parameter: A parameter whose value is left open by the Metric 
and its Measurement Method and is set to a specific value ina 
Measurement Task. Altering the value of an Input Parameter does not 
change the fundamental nature of the Measurement Task. 


Instruction: The description of Measurement Tasks for an MA to 
perform and the details of the Report for it to send. It is the 
collective description of the Measurement Task configurations, the 
configuration of the Measurement Schedules, the configuration of the 
Report Channel(s), the configuration of Report Schedule(s), and the 
details of any Suppression. 


Instruction Message: The message that carries an Instruction from a 
Controller to a Measurement Agent. 


Logging Information: Information about the operation of the 
Measurement Agent, which may be useful for debugging. 


Measurement Agent (MA): The function that receives Instruction 
Messages from a Controller and operates the Instruction by executing 
Measurement Tasks (using protocols outside the scope of the initial 
LMAP work and perhaps in concert with one or more other Measurement 
Agents or Measurement Peers) and (if part of the Instruction) by 
reporting Measurement Results to a Collector or Collectors. 


Measurement Agent Identifier (MA-ID): a Universally Unique IDentifier 
[RFC4122] that identifies a particular MA and is configured as part 
of the Bootstrapping process. 


Measurement Method: The process for assessing the value of a Metric; 
the process of measuring some performance or reliability Metric 
associated with the transfer of traffic. 

Measurement Peer (MP): The function that assists a Measurement Agent 
with Measurement Tasks and does not have an interface to the 


Controller or Collector. 


Measurement Result: The output of a single Measurement Task (the 
value obtained for the Metric). 


Measurement Schedule: The schedule for performing Measurement Tasks. 
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Measurement System: The set of LMAP-defined and related components 
that are operated by a single organisation, for the purpose of 
measuring performance aspects of the network. 


Measurement Task: The action performed by a particular Measurement 
Agent that consists of the single assessment of a Metric through 
operation of a Measurement Method role at a particular time, with all 
of the role’s Input Parameters set to specific values. 


Measurement Traffic: the packet(s) generated by some types of 
Measurement Method that involve measuring some parameter associated 
with the transfer of the packet(s). 


Metric: The quantity related to the performance and reliability of 
the network that we’d like to know the value of. 


Observed Traffic Flow: In RFC 7011 [RFC7011], a Traffic Flow (or 
Flow) is defined as "a set of packets or frames passing an 
Observation Point in the network during a certain time interval. All 
packets belonging to a particular Flow have a set of common 
properties," such as packet header fields, characteristics, and 
treatments. A Flow measured by the LMAP system is termed an Observed 
Traffic Flow. Its properties are summarised and tabulated in 
Measurement Results (as opposed to raw capture and export). 


Report: The set of Measurement Results and other associated 
information (as defined by the Instruction). The Report is sent by a 


Measurement Agent to a Collector. 


Report Channel: A Channel between a Collector and an MA over which 
Report messages are sent. 


Report Protocol: The protocol delivering Report(s) from a Measurement 
Agent to a Collector. It runs over the Report Channel. 


Report Schedule: The schedule for sending Reports to a Collector. 


Subscriber: An entity (associated with one or more users) that is 
engaged in a subscription with a service provider. 


Suppression: The temporary cessation of Measurement Tasks. 
4. Constraints 


The LMAP framework makes some important assumptions, which constrain 
the scope of the initial LMAP work. 
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4.1. The Measurement System Is Under the Direction of a Single 
Organisation 


In the LMAP framework, the Measurement System is under the direction 
of a single organisation that is responsible for any impact that its 
measurements have on a user’s quality of experience and privacy. 
Clear responsibility is critical given that a misbehaving large-scale 
Measurement System could potentially harm user experience, user 
privacy, and network security. 


However, the components of an LMAP Measurement System can be deployed 
in administrative domains that are not owned by the measuring 
organisation. Thus, the system of functions deployed by a single 
organisation constitutes a single LMAP domain, which may span 
ownership or other administrative boundaries. 


4.2. Each MA May Only Have a Single Controller at Any Point in Time 


An MA is instructed by one Controller and is in one Measurement 
System. The constraint avoids different Controllers giving an MA 
conflicting instructions and so means that the MA does not have to 
manage contention between multiple Measurement (or Report) Schedules. 
This simplifies the design of MAs (critical for a large-scale 
infrastructure) and allows a Measurement Schedule to be tested on 
specific types of MAs before deployment to ensure that the end-user 
experience is not impacted (due to CPU, memory, or broadband-product 
constraints). However, a Measurement System may have several 
Controllers. 


5. Protocol Model 


A protocol model [RFC4101] presents an architectural model for how 
the protocol operates and needs to answer three basic questions: 


1. What problem is the protocol trying to address? 


2. What messages are being transmitted and what do they mean? 


3. What are the important, but not obvious [sic], features of the 
protocol? 


An LMAP system goes through the following phases: 


o a Bootstrapping process before the MA can take part in the other 
three phases. 


o a Control Protocol, which delivers Instruction Messages from a 
Controller to an MA (amongst other things). 
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o the actual Measurement Tasks, which measure some performance or 
reliability Metric(s) associated with the transfer of packets. 


o a Report Protocol, which delivers Reports containing the 
Measurement Results from an MA to a Collector. 


The figures show the various LMAP messages and use the following 
conventions: 


o (optional): indicated by round brackets 
o [potentially repeated]: indicated by square brackets 


The protocol model is closely related to the Information Model 
[LMAP-INFO], which is the abstract definition of the information 
carried by the protocol. (If there is any difference between this 
document and the Information Model, the latter is definitive.) The 
purpose of both is to provide a protocol and device-independent view, 
which can be implemented via specific protocols. LMAP defines a 
specific Control Protocol and Report Protocol, but others could be 
defined by other standards bodies or be proprietary. However, it is 
important that they all implement the same Information Model and 
protocol model, in order to ease the definition, operation, and 
interoperability of large-scale Measurement Systems. 


5.1. Bootstrapping Process 


The primary purpose of Bootstrapping is to enable an MA to be 
integrated into a Measurement System. The MA retrieves information 
about itself (like its identity in the Measurement System) and about 
the Controller, the Controller learns information about the MA, and 
they learn about security information to communicate (such as 
certificates and credentials). 


Whilst this memo considers the Bootstrapping process, it is beyond 
the scope of initial LMAP work to define a Bootstrap mechanism, as it 
depends on the type of device and access. 


As a result of the Bootstrapping process, the MA learns the following 
information ([LMAP-INFO] defines the consequent list of information 
elements): 


o its identifier, either its MA-ID or a device identifier such as 
one of its Media Access Control (MAC) addresses or both. 


o (optionally) a Group-ID, shared by several MAs and could be useful 
for privacy reasons. For instance, reporting the Group-ID and not 
the MA-ID could hinder tracking of a mobile device. 
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o the Control Channel, which is defined by: 


* the address that identifies the Control Channel, such as the 
Controller’s FODN (Fully Qualified Domain Name) [RFC1035]). 


* security information (for example, to enable the MA to decrypt 
the Instruction Message and encrypt messages sent to the 
Controller). 


The details of the Bootstrapping process are device/access specific. 
For example, the information could be in the firmware, manually 
configured, or transferred via a protocol like that described in 


TR-069 [TR-069]. There may be a multi-stage process where the MA 
contacts a 'hard-coded” address, which replies with the Bootstrapping 
information. 


The MA must learn its MA-ID before getting an Instruction, either 
during Bootstrapping or via Configuration (Section 5.2.1). 


5.2. Control Protocol 


The primary purpose of the Control Protocol is to allow the 
Controller to configure a Measurement Agent with an Instruction about 
what Measurement Tasks to do, when to do them, and how to report the 
Measurement Results (Section 5.2.2). The Measurement Agent then acts 
on the Instruction autonomously. The Control Protocol also enables 
the MA to inform the Controller about its Capabilities and any 


Failure and Logging Information (Section 5.2.3). Finally, the 
Control Protocol allows the Controller to update the MA’s 
Configuration. 


5.2.1. Configuration 


Configuration allows the Controller to update the MA about some or 
all of the information that it obtained during the Bootstrapping 
process: the MA-ID, the (optional) Group-ID, and the Control Channel. 
Figure 2 outlines the Configuration process. The Measurement System 
might use Configuration for several reasons. For example, the 
Bootstrapping process could 'hard code’ the MA with details of an 
initial Controller, and then the initial Controller could configure 
the MA with details about the Controller that sends Instruction 
Messages. (Note that an MA only has one Control Channel, so it is 
associated with only one Controller, at any moment.) 


Note that an implementation may choose to combine Configuration 
information and an Instruction Message into a single message. 
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fatet ete + SHE + 
| | | Measurement | 
| Controller | | Agent | 
+----------------- + $ + 
Configuration information: => 

(MA-ID), 

(Group-ID), 


(Control Channel) 
<- Response (details) 


MA: Measurement Agent 
Figure 2: Outline of Configuration 
5.2.2. Instruction 


The Instruction is the description of the Measurement Tasks for a 
Measurement Agent to do and the details of the Measurement Reports 
for it to send. Figure 3 outlines the Instruction process. In order 
to update the Instruction, the Controller uses the Control Protocol 
to send an Instruction Message over the Control Channel. 


+----------------- + +------------- + 
| | | Measurement | 
| Controller | | Agent | 
+----------------- + $------------- + 
Instruction: => 


[ (Measurement Task configuration 
URI of Metric ( 
[Input Parameter], 
(role) 
(interface), 
(Cycle-ID) 
(measurement point)), 
(Report Channel), 
(Schedule), 
(Suppression information) ] 
<- Response (details) 


Figure 3: Outline of Instruction 
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The Instruction defines the following information ([LMAP-INFO] 
defines the consequent list of information elements): 


o the Measurement Task configurations, each of which needs: 


* the Metric, specified as a URI to a registry entry; it includes 
the specification of a Measurement Method. The registry could 
be defined by a standards organisation or locally by the 
operator of the Measurement System. Note that, at the time of 
writing, the IETF is working on such a registry specification 
[IPPM-REG]. 


* the Measurement Method role. For some Measurement Methods, 
different parties play different roles; for example, an iperf 
sender and receiver (see Section 6.4). Each Metric and its 
associated Measurement Method will describe all measurement 
roles involved in the process. 


* a boolean flag (suppress or do-not-suppress) indicating if such 
a Measurement Task is impacted by a Suppression message (see 
Section 5.2.2.1). Thus, the flag is an Input Parameter. 


* any Input Parameters that need to be set for the Metric and the 
Measurement Method. For example, the address of a Measurement 
Peer (or other Measurement Agent) that may be involved in a 
Measurement Task, or traffic filters associated with the 
Observed Traffic Flow. 


* the interface to use (if not defined, then the default 
interface is used), if the device with the MA has multiple 
interfaces. 


* optionally, a Cycle-ID. 
* optionally, the measurement point designation [RFC7398] of the 
MA and, if applicable, of the MP or other MA. This can be 


useful for reporting. 


o configuration of the Schedules, each of which needs: 


* the timing of when the Measurement Tasks are to be performed or 
the Measurement Reports are to be sent. Possible types of 
timing are periodic, calendar-based periodic, one-off 
immediate, and one-off at a future time. 
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o configuration of the Report Channel(s), each of which needs: 
* the address of the Collector, for instance its URL. 


* security for this Report Channel, for example, the X.509 
certificate. 


o Suppression information, if any (see Section 5.2.2.1). 


A single Instruction Message may contain some or all of the above 
parts. The finest level of granularity possible in an Instruction 
Message is determined by the implementation and operation of the 
Control Protocol. For example, a single Instruction Message may add 
or update an individual Measurement Schedule -- or it may only update 
the complete set of Measurement Schedules; a single Instruction 
Message may update both Measurement Schedules and Measurement Task 
configurations -- or only one at a time; and so on. However, 
Suppression information always replaces (rather than adds to) any 
previous Suppression information. 


The MA informs the Controller that it has successfully understood the 
Instruction Message, or that it cannot take action on the Instruction 
-- for example, if it doesn’t include a parameter that is mandatory 
for the requested Metric and Measurement Method, or if it is missing 
details of the target Collector. 


The Instruction Message instructs the MA; the Control Protocol does 
not allow the MA to negotiate, as this would add complexity to the 
MA, Controller, and Control Protocol for little benefit. 


5.2.2.1. Suppression 


The Instruction may include Suppression information. The main 
motivation for Suppression is to enable the Measurement System to 
eliminate Measurement Traffic, because there is some unexpected 
network issue, for example. There may be other circumstances when 
Suppression is useful, for example, to eliminate inessential 
Reporting traffic (even if there is no Measurement Traffic). 
Figure 4 outlines the Suppression process. 


The Suppression information may include any of the following optional 
fields: 


o a set of Measurement Tasks to suppress; the others are not 
suppressed. For example, this could be useful if a particular 
Measurement Task is overloading a Measurement Peer with 
Measurement Traffic. 
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o 


a set of Measurement Schedules to suppress; the others are not 
suppressed. For example, suppose the Measurement System has 
defined two Schedules, one with the most critical Measurement 
Tasks and the other with less critical ones that create a lot of 
Measurement Traffic, in which case it may only want to suppress 
the second. 


a set of Reporting Schedules to suppress; the others are not 
suppressed. This can be particularly useful in the case of a 
Measurement Method that doesn't generate Measurement Traffic; it 
may need to continue observing traffic flows but temporarily 
suppress Reports due to the network footprint of the Reports. 


if all the previous fields are included then the MA suppresses the 
union -- in other words, it suppresses the set of Measurement 
Tasks, the set of Measurement Schedules, and the set of Reporting 
Schedules. 


if the Suppression information includes neither a set of 
Measurement Tasks nor a set of Measurement Schedules, then the MA 
does not begin new Measurement Tasks that have the boolean flag 
set to suppress; however, the MA does begin new Measurement Tasks 
that have the flag set to do-not-suppress. 


a start time, at which Suppression begins. If absent, then 
Suppression begins immediately. 


an end time, at which Suppression ends. If absent, then 
Suppression continues until the MA receives an Un-suppress 
message. 


a demand that the MA immediately end on-going Measurement Task (s) 
that are tagged for Suppression. (Most likely it is appropriate 
to delete the associated partial Measurement Result(s).) This 
could be useful in the case of a network emergency so that the 
operator can eliminate all inessential traffic as rapidly as 
possible. If absent, the MA completes on-going Measurement Tasks. 


An Un-suppress message instructs the MA to no longer suppress, 
meaning that the MA once again begins new Measurement Tasks, 
according to its Measurement Schedule. 


Note that Suppression is not intended to permanently stop a 
Measurement Task (instead, the Controller should send a new 
Measurement Schedule), nor to permanently disable an MA (instead, 
some kind of management action is suggested). 
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Ze 


+----------------- + +------------- + 
| | | Measurement | 
| Controller | | Agent | 
+----------------- + +------------- + 
Suppress: 

[ (Measurement Task), => 


Measurement Schedule), 
start time), 

end time), 

on-going suppressed?) ] 


( 
( 
( 
( 
Un-suppress -> 
Figure 4: Outline of Suppression 
3. Capabilities, Failure, and Logging Information 
The Control Protocol also enables the MA to inform the Controller 
about various information, such as its Capabilities and any Failures. 
Figure 5 outlines the process for Capabilities, Failure, and Logging 
Information. It is also possible to use a device-specific mechanism, 


which is beyond the scope of the initial LMAP work. 


Capabilities are information about the MA that the Controller needs 
to know in order to correctly instruct the MA, such as: 


o the Measurement Method (roles) that the MA supports. 

o the measurement protocol types and roles that the MA supports. 
o the interfaces that the MA has. 

o the version of the MA. 


o the version of the hardware, firmware, or software of the device 
with the MA. 


o its Instruction (this could be useful if the Controller thinks 
something has gone wrong and wants to check what Instruction the 
MA is using). 


o but not dynamic information like the currently unused CPU, memory, 
or battery life of the device with the MA. 
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Failure Information concerns why the MA has been unable to execute a 
Measurement Task or deliver a Report, for example: 


o the Measurement Task failed to run properly because the MA 
(unexpectedly) has no spare CPU cycles. 


o the MA failed to record the Measurement Results because it 
(unexpectedly) is out of spare memory. 


o a Report failed to deliver Measurement Results because the 
Collector (unexpectedly) is not responding. 


o but not if a Measurement Task correctly doesn’t start. For 
example, the first step of some Measurement Methods is for the MA 


to check that there is no cross-traffic. 


Logging Information concerns how the MA is operating and may help 
debugging, for example: 


o the last time the MA ran a Measurement Task. 
o the last time the MA sent a Measurement Report. 


o the last time the MA received an Instruction Message. 


o whether the MA is currently suppressing Measurement Tasks. 


Capabilities, Failure, and Logging Information are sent by the MA, 
either in response to a request from the Controller (for example, if 
the Controller forgets what the MA can do or otherwise wants to 
resynchronise what it knows about the MA), or on its own initiative 
(for example, when the MA first communicates with a Controller or if 
it becomes capable of a new Measurement Method). Another example of 
the latter case is if the device with the MA re-boots, then the MA 
should notify its Controller in case its Instruction needs to be 
updated; to avoid a "mass calling event" after a widespread power 
restoration affecting many MAs, it is sensible for an MA to pause for 
a random delay, perhaps in the range of one minute or so. 
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| Controller | | Agent | 


Request Capabilities), 
Request Failure Information), 
Request Logging Information), 
Request Instruction) => 
<- (Capabilities), 
(Failure Information), 
) 
) 


anana 


(Logging Information 
(Instruction 


r 


Figure 5: Outline of Capabilities, Failure, and Logging Information 
5.3. Operation of Measurement Tasks 


This LMAP framework is neutral to what the actual Measurement Task 
is. It does not define Metrics and Measurement Methods; these are 
defined elsewhere. 


The MA carries out the Measurement Tasks as instructed, unless it 
gets an updated Instruction. The MA acts autonomously, in terms of 
operation of the Measurement Tasks and reporting of the Results; it 
doesn't do a 'safety check’ with the Controller to ask whether it 
should still continue with the requested Measurement Tasks. 


The MA may operate Measurement Tasks sequentially or in parallel (see 
Section 5.3.2). 


5.3.1. Starting and Stopping Measurement Tasks 


This LMAP framework does not define a generic start and stop process, 
since the correct approach depends on the particular Measurement 
Task; the details are defined as part of each Measurement Method. 
This section provides some general hints. The MA does not inform the 
Controller about Measurement Tasks starting and stopping. 


Before beginning a Measurement Task, the MA may want to run a 
pre-check. (The pre-check could be defined as a separate, preceding 


Task or as the first part of a larger Task.) 


For Measurement Tasks that observe existing traffic, action could 
include: 


o checking that there is traffic of interest. 
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o checking that the device with the MA has enough resources to 
execute the Measurement Task reliably. Note that the designer of 
the Measurement System should ensure that the device’s resources 
are normally sufficient to comfortably operate the Measurement 
Tasks. 


For Measurement Tasks that generate Measurement Traffic, a pre-check 
could include: 


o the MA checking that there is no cross-traffic. In other words, a 
check that the end-user isn’t already sending traffic. 


o the MA checking with the Measurement Peer (or other Measurement 
Agent) involved in the Measurement Task that it can handle a new 
Measurement Task. For example, the Measurement Peer may already 
be handling many Measurement Tasks with other MAs. 


o sending traffic that probes the path to check it isn’t overloaded. 


o checking that the device with the MA has enough resources to 
execute the Measurement Task reliably. 


Similar checks may continue during the Measurement Task, in 
particular for a Measurement Task that is long-running and/or creates 
a lot of Measurement Traffic. If, for example, the check detects 
that the end-user has started sending traffic, then the Measurement 
Task can be abandoned. A Measurement Task could also be abandoned in 
response to a "Suppress" message (see Section 5.2.2.1). Action could 
include: 


o for ‘upload’ tests, the MA not sending traffic. 


o for ‘download’ tests, the MA closing the TCP connection or sending 
a TWAMP (Two-Way Active Measurement Protocol) Stop-Sessions 
command [RFC5357]. 


The Controller may want an MA to run the same Measurement Task 
indefinitely (for example, "run the ’upload speed’ Measurement Task 
once an hour until further notice"). To prevent the MA continuously 
generating traffic after a Controller has permanently failed (or 
communications with the Controller have failed), the MA can be 
configured with a time limit; if the MA doesn’t hear from the 
Controller for this length of time, then it stops operating 
Measurement Tasks. 
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5.3.2. Overlapping Measurement Tasks 


An MA may start a new Measurement Task before another Measurement 
Task has completed. This may be intentional (the way that the 
Measurement System has designed the Measurement Schedules), but it 
could also be unintentional -- for instance, if a Measurement Task 
has a 'wait for X’ step that pauses for an unexpectedly long time. 
This document makes no assumptions about the impact of one 
Measurement Task on another. 


The operator of the Measurement System can handle (or not) 
overlapping Measurement Tasks in any way they choose -- it isa 
policy or implementation issue and not the concern of LMAP. Some 
possible approaches are: to configure the MA to not begin the second 
Measurement Task; to start the second Measurement Task as usual; for 
the action to be an Input Parameter of the Measurement Task; and so 
on. 


It may be important for the Measurement Report to include the fact 
that the Measurement Tasks overlapped. 


5.4. Report Protocol 


The primary purpose of the Report Protocol is to allow a Measurement 
Agent to report its Measurement Results to a Collector, along with 
the context in which they were obtained. Figure 6 outlines the 
Report process. 


| Collector | | Agent | 


<- Report: 
[MA-ID &/or Group-ID], 
[Measurement Result], 
[details of Measurement Task], 
(Cycle-ID) 
ACK => 
MA: Measurement Agent 
Figure 6: Outline of the Report 


The Report contains: 


o the MA-ID or a Group-ID (to anonymise results). 
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o the actual Measurement Results, including the time they were 
measured. In general, the time is simply the MA’s best estimate 
and there is no guarantee on the accuracy or granularity of the 
information. It is possible that some specific analysis of a 
particular Measurement Method’s Results will impose timing 
requirements. 


o the details of the Measurement Task (to avoid the Collector having 
to ask the Controller for this information later), for example, 
the interface used for the measurements. 


o the Cycle-ID, if one was included in the Instruction. 
o perhaps the Subscriber’s service parameters (see Section 5.4.1). 


o the measurement point designation of the MA and, if applicable, 
the MP or other MA, if the information was included in the 
Instruction. This numbering system is defined in [RFC7398] and 
allows a Measurement Report to describe the path measured 
abstractly (for example, "from a measurement agent at a home 
gateway to a measurement peer at a DSLAM"). Also, the MA can 
anonymise results by including measurement point designations 
instead of IP addresses (Section 8.6.2). 


The MA sends Reports as defined by the Instruction. The Instruction 
may tell the MA to report the same Results to more than one 
Collector, or to report a different subset of Results to different 
Collectors. Also, a Measurement Task may create two (or more) 
Measurement Results, which could be reported differently (for 
example, one Result could be reported periodically, whilst the second 
Result could be an alarm that is created as soon as the measured 
value of the Metric crosses a threshold and that is reported 
immediately). 


Optionally, a Report is not sent when there are no Measurement 
Results. 


In the initial LMAP Information Model and Report Protocol, for 
simplicity we assume that all Measurement Results are reported as-is, 
but allow extensibility so that a Measurement System (or perhaps a 
second phase of LMAP) could allow an MA to: 


o label, or perhaps not include, Measurement Results impacted by, 
for instance, cross-traffic or a Measurement Peer (or other 
Measurement Agent) being busy. 


o label Measurement Results obtained by a Measurement Task that 
overlapped with another. 
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o not report the Measurement Results if the MA believes that they 
are invalid. 


o detail when Suppression started and ended. 


As discussed in Section 6.1, data analysis of the Results should 
carefully consider potential bias from any Measurement Results that 
are not reported, or from Measurement Results that are reported but 
may be invalid. 


5.4.1. Reporting of the Subscriber’s Service Parameters 


The Subscriber’s service parameters are information about his/her 
broadband contract, line rate and so on. Such information is likely 
to be needed to help analyse the Measurement Results, for example to 
help decide whether the measured download speed is reasonable. 


The information could be transferred directly from the Subscriber 
parameter database to the data analysis tools. If the Subscriber’s 
service parameters are available to the MAs, they could be reported 
with the Measurement Results in the Report Protocol. How (and if) 
the MA knows such information is likely to depend on the device type. 
The MA could either include the information in a Measurement Report 
or separately. 


5.5. Operation of LMAP over the Underlying Packet Transfer Mechanism 


The above sections have described LMAP’s protocol model. Other 
specifications will define the actual Control and Report Protocols, 
possibly operating over an existing protocol, such as REST-style 
[REST] HTTP(S). It is also possible that a different choice is made 
for the Control and Report Protocols, for example NETCONF-YANG 
[RFC6241] and IPFIX (Internet Protocol Flow Information Export) 
[RFC7011], respectively. 


From an LMAP perspective, the Controller needs to know that the MA 
has received the Instruction Message, or at least that it needs to be 
re-sent as it may have failed to be delivered. Similarly the MA 
needs to know about the delivery of Capabilities, Failure, and 
Logging Information to the Controller and Reports to the Collector. 
How this is done depends on the design of the Control and Report 
Protocols and the underlying packet transfer mechanism. 


For the Control Protocol, the underlying packet transfer mechanism 
could be: 


o a ‘push’ protocol (that is, from the Controller to the MA). 
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o a multicast protocol (from the Controller to a group of MAs). 


o a ‘pull’ protocol. The MA periodically checks with Controller if 
the Instruction has changed and pulls a new Instruction if 
necessary. A pull protocol seems attractive for an MA behind a 
NAT or firewall (as is typical for an MA on an end-user’s device) 
so that it can initiate the communications. It also seems 
attractive for an MA on a mobile device, where the Controller 
might not know how to reach the MA. A pull mechanism is likely to 
require that the MA be configured with how frequently it should 
check in with the Controller, and perhaps what it should do if the 
Controller is unreachable after a certain number of attempts. 


o a hybrid protocol. In addition to a pull protocol, the Controller 
can also push an alert to the MA that it should immediately pull a 
new Instruction. 


For the Report Protocol, the underlying packet transfer mechanism 
could be: 


o a ‘push’ protocol (that is, from the MA to the Collector) 


o perhaps supplemented by the ability for the Collector to ’pull’ 
Measurement Results from an MA. 


5.6. Items beyond the Scope of the Initial LMAP Work 


There are several potential interactions between LMAP elements that 
are beyond the scope of the initial LMAP work, which are as follows: 


1. It does not define a coordination process between MAs. Whilst a 
Measurement System may define coordinated Measurement Schedules 
across its various MAs, there is no direct coordination between 
MAs. 


2. It does not define interactions between the Collector and 
Controller. It is quite likely that there will be such 
interactions, optionally intermediated by the data analysis 
tools. For example, if there is an "interesting" Measurement 
Result, then the Measurement System may want to trigger extra 
Measurement Tasks that explore the potential cause in more 
detail; or if the Collector unexpectedly does not hear from an 
MA, then the Measurement System may want to trigger the 
Controller to send a fresh Instruction Message to the MA. 
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5.6. 


Tes 


It does not define coordination between different Measurement 
Systems. For example, it does not define the interaction of an 
MA in one Measurement System with a Controller or Collector ina 
different Measurement System. Whilst it is likely that the 
Control and Report Protocols could be re-used or adapted for this 
scenario, any form of coordination between different 
organisations involves difficult commercial and technical issues 
and so, given the novelty of large-scale measurement efforts, any 
form of inter-organisation coordination is outside the scope of 
the initial LMAP work. Note that a single MA is instructed by a 
single Controller and is only in one Measurement System. 


* An interesting scenario is where a home contains two 
independent MAs, for example one controlled by a regulator and 


one controlled by an ISP. Then the Measurement Traffic of one 
MA is treated by the other MA just like any other end-user 
traffic. 


It does not consider how to prevent a malicious party "gaming the 
system". For example, where a regulator is running a Measurement 
System in order to benchmark operators, a malicious operator 
could try to identify the broadband lines that the regulator was 
measuring and prioritise that traffic. It is assumed that this 
is a policy issue and would be dealt with through a code of 
conduct for instance. 


It does not define how to analyse Measurement Results, including 
how to interpret missing Results. 


It does not specifically define a end-user-controlled Measurement 
System, see Section 5.6.1. 


End-User-Controlled Measurement System 


This framework concentrates on the cases where an ISP or a regulator 
runs the Measurement System. However, we expect that LMAP 
functionality will also be used in the context of an end-user- 
controlled Measurement System. There are at least two ways this 
could happen (they have various pros and cons): 


T; 


an end-user could somehow request the ISP-run (or regulator-run) 
Measurement System to test his/her line. The ISP (or regulator) 
Controller would then send an Instruction to the MA in the usual 
LMAP way. 
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6. 


6. 


2. an end-user could deploy their own Measurement System, with their 
own MA, Controller, and Collector. For example, the user could 
implement all three functions onto the same end-user-owned end 
device, perhaps by downloading the functions from the ISP or 
regulator. Then the LMAP Control and Report Protocols do not 
need to be used, but using LMAP’s Information Model would still 
be beneficial. A Measurement Peer (or other MA involved in a 
Measurement Task) could be in the home gateway or outside the 
home network; in the latter case, the Measurement Peer is highly 
likely to be run by a different organisation, which raises extra 
privacy considerations. 


In both cases, there will be some way for the end-user to initiate 
the Measurement Task(s). The mechanism is outside the scope of the 
initial LMAP work, but could include the user clicking a button on a 
GUI or sending a text message. Presumably the user will also be able 
to see the Measurement Results, perhaps summarised on a webpage. It 
is suggested that these interfaces conform to the LMAP guidance on 
privacy in Section 8. 


Deployment Considerations 
1. Controller and the Measurement System 


The Controller should understand both the MA's LMAP Capabilities (for 
example, what Metrics and Measurement Methods it can perform) and the 
MA’s other capabilities like processing power and memory. This 
allows the Controller to ensure that the Measurement Schedule of 
Measurement Tasks and the Reporting Schedule are sensible for each MA 
that it instructs. 


An Instruction is likely to include several Measurement Tasks. 
Typically these run at different times, but it is also possible for 


them to run at the same time. Some Tasks may be compatible in that 
they do not affect each other's Results, whilst with others great 
care would need to be taken. Some Tasks may be complementary. For 


example, one Task may be followed by a traceroute Task to the same 
destination address, in order to learn the network path that was 
measured. 


The Controller should ensure that the Measurement Tasks do not have 
an adverse effect on the end user. Tasks, especially those that 
generate a substantial amount of Measurement Traffic, will often 
include a pre-check that the user isn’t already sending traffic 
(Section 5.3.1). Another consideration is whether Measurement 
Traffic will impact a Subscriber’s bill or traffic cap. 
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A Measurement System may have multiple Controllers (but note the 
overriding principle that a single MA be instructed by a single 
Controller at any point in time (Section 4.2)). For example, there 
could be different Controllers for different types of MA (for 
example, home gateways, tablets) or locations (for example, Ipswich, 
Edinburgh, Paris), for load balancing or to cope with failure of one 
Controller. 


The measurement system also needs to consider carefully how to 
interpret missing Results. The correct interpretation depends on why 
the Results are missing (perhaps related to measurement Suppression 
or delayed Report submission) and potentially on the specifics of the 
Measurement Task and Measurement Schedule. For example, an Observed 
Traffic Flow may be empty, but the Measurement Report may still be 
sent according to the Report Schedule. 


6.2. Measurement Agent 


The MA should be cautious about resuming Measurement Tasks if it 
reboots or has been offline for some time, as its Instruction may be 
stale. In the former case, it also needs to ensure that its clock 
has reset correctly, so that it interprets the Schedule correctly. 


If the MA runs out of storage space for Measurement Results or can’t 
contact the Controller, then the appropriate action is specific to 
the device and Measurement System. 


The Measurement Agent could take a number of forms. For example, an 
MA could be a dedicated probe or software on a PC; it could also be 
embedded into an appliance or even embedded into a gateway. A single 
site (for example, home, branch office, etc.) that is participating 
in a measurement could make use of one or multiple Measurement Agents 
or Measurement Peers in a single measurement. 


The Measurement Agent could be deployed in a variety of locations. 
Not all deployment locations are available to every kind of 
Measurement Agent. There are also a variety of limitations and 
trade-offs depending on the final placement. The next sections 
outline some of the locations a Measurement Agent may be deployed. 
This is not an exhaustive list and combinations may also apply. 


6.2.1. Measurement Agent on a Networked Device 


An MA may be embedded on a device that is directly connected to the 
network, such as an MA on a smartphone. Other examples include an MA 
downloaded and installed on a subscriber’s laptop computer or tablet 
when the network service is provided on wired or other wireless radio 
technologies, such as Wi-Fi. 
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6.2.2. Measurement Agent Embedded in a Site Gateway 


One of the better places the Measurement Agent could be deployed is 
embedded within the site gateway (for example, a home router or the 
edge router of a branch office in a managed service environment). 

All site-to-ISP traffic would traverse through the gateway. So, 
Measurement Methods that measure user traffic could easily be 
performed. Similarly, due to this user traffic visibility, a 
Measurement Method that generates Measurement Traffic could ensure it 
does not compete with user traffic. Generally NAT and firewall 
services are built into the gateway, allowing the Measurement Agent 
the option to offer its Controller-facing management interface 
outside of the NAT/firewall. This placement of the management 
interface allows the Controller to unilaterally contact the 
Measurement Agent with Instructions. However, a Measurement Agent on 
a site gateway (whether end-user or service-provider owned) will 
generally not be directly available for over-the-top providers, the 
regulator, end users, or enterprises. 


6.2.3. Measurement Agent Embedded behind a Site NAT or Firewall 


The Measurement Agent could also be embedded behind a NAT, a 
firewall, or both. In this case, the Controller may not be able to 
unilaterally contact the Measurement Agent unless either static port 
forwarding or firewall pin holing is configured. Configuring port 
forwarding could use protocols such as the Port Control Protocol 
[RFC6887], the CPE WAN Management Protocol [TR-069], or Universal 
Plug and Play [UPnP]. To open a pin hole in the firewall, the 
Measurement Agent could send keepalives towards the Controller (and 
perhaps use these also as a network reachability test). 


6.2.4. Multihomed Measurement Agent 


If the device with the Measurement Agent is single homed, then there 
is no confusion about what interface to measure. Similarly, if the 
MA is at the gateway and the gateway only has a single WAN-side and a 
single LAN-side interface, there is little confusion -- for 
Measurement Methods that generate Measurement Traffic, the location 
of the other MA or Measurement Peer determines whether the WAN or LAN 
is measured. 


However, the device with the Measurement Agent may be multihomed. 

For example, a home or campus may be connected to multiple broadband 
ISPs, such as a wired and wireless broadband provider, perhaps for 
redundancy or load sharing. It may also be helpful to think of dual 
stack IPv4 and IPv6 broadband devices as multihomed. More generally, 
Section 3.2 of [RFC7368] describes dual-stack and multihoming 
topologies that might be encountered in a home network, [RFC6419] 
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provides the current practices of multi-interfaces hosts, and the 
Multiple Interfaces (mif) working group covers cases where hosts are 
either directly attached (for example, physical or virtual) or 
indirectly (for example, multiple default routers, etc.) to multiple 
networks. In these cases, there needs to be clarity on which network 
connectivity option is being measured. 


One possibility is to have a Measurement Agent per interface. Then 
the Controller’s choice of MA determines which interface is measured. 
However, if an MA can measure any of the interfaces, then the 
Controller defines in the Instruction which interface the MA should 
use for a Measurement Task. If the choice of interface is not 
defined, then the MA uses the default one. Explicit definition is 
preferred if the Measurement System wants to measure the performance 
of a particular network, whereas using the default is better if the 
Measurement System wants to include the impact of the MA’s interface 
selection algorithm. In any case, the Measurement Result should 
include the network that was measured. 


6.2.5. Measurement Agent Embedded in an ISP Network 


An MA may be embedded on a device that is part of an ISP’s network, 
such as a router or switch. Usually the network devices with an 
embedded MA will be strategically located, such as a Carrier-Grade 
NAT or ISP Gateway. [RFC7398] gives many examples where an MA might 
be located within a network to provide an intermediate measurement 
point on the end-to-end path. Other examples include a network 
device whose primary role is to host MA functions and the necessary 
measurement protocol. 


6.3. Measurement Peer 


A Measurement Peer participates in some Measurement Methods. It may 
have specific functionality to enable it to participate ina 
particular Measurement Method. On the other hand, other Measurement 
Methods may require no special functionality. For example, if the 
Measurement Agent sends a ping to example.com, then the server at 
example.com plays the role of a Measurement Peer; or if the MA 
monitors existing traffic, then the existing end points are 
Measurement Peers. 


A device may participate in some Measurement Methods as a Measurement 
Agent and in others as a Measurement Peer. 


Measurement Schedules should account for limited resources in a 

Measurement Peer when instructing an MA to execute measurements with 
a Measurement Peer. In some measurement protocols, such as [RFC4656] 
and [RFC5357], the Measurement Peer can reject a measurement session 
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or refuse a control connection prior to setting up a measurement 
session and so protect itself from resource exhaustion. This is a 
valuable capability because the MP may be used by more than one 
organisation. 


6.4. Deployment Examples 


In this section, we describe some deployment scenarios that are 
feasible within the LMAP framework defined in this document. 


A very simple example of a Measurement Peer (MP) is a web server from 
which the MA downloads a web page (such as www.example.com) in order 


to perform a speed test. The web server is an MP and from its 
perspective the MA is just another client; the MP doesn’t have a 
specific function for assisting measurements. This is described in 
Figure 7. 
Poa peas Sao eee +- web traffic ="=2=52===$=5=== + non-LMAP 
| web client | <------------ > web server | Scope 
| | t---------------- + | 
A A A Ad Sa Maz 
MA:LMAP interface <MP> A 
+------------------ + | 
à | | 
Instruction | | Report 
| Ho + | 
| 
| v LMAP 
AIRE + a pA ae a ae + Scope 
Controller | Collector 
do + A A + vV 


MA: Measurement Agent 
MP: Measurement Peer 


Figure 7: LMAP deployment example, with Web server as Measurement 
Peer 


Another example of an MP is a TWAMP Server and TWAMP 
Session-Reflector. This form of MP is deployed to assist the MAs 
that perform TWAMP tests, where the MA is co-located with the TWAMP 
Control-Client and Session-Sender. Another example, which was 
described in Section 2, has a ping server as the Measurement Peer. 
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A further example is the case of a traceroute-like measurement. In 
this case, for each packet sent, the router where the TTL expires is 
performing the MP function. So for a given Measurement Task, there 
is one MA involved and several MPs, one per hop. 


In Figure 8, we depict the case of an OWAMP (One-Way Active 
Measurement Protocol) Server and Session-Receiver acting as an MP. 
In this case, the OWAMP Server conveys results back to the OWAMP 
Fetch-Client, thus the MP conducts both control-plane and data-plane 
communications with its OWAMP counterparts co-located with the MA. 


aa A + OWAMP popa + A 
| OWAMP |<--control--->| | 
| control-client |-test-traffic>| OWAMP server & | non-LMAP 
| fetch-client & |<----fetch----| session-receiver| Scope 
| session-sender | | 
+----------------- + 
aaa a nee AS e 
|MA:LMAP interface | <MP> A 
+------------------ + | 
^ | | 
Instruction | Report 
+----------------- + 
| | 
| v LMAP 
a SÓ $ ya TS += PS 2575 + Scope 
Controller | Collector 
4+------------ + 4+------------ + v 


MA: Measurement Agent 
MP: Measurement Peer 


Figure 8: LMAP deployment example, with OWAMP server as Measurement 
Peer 


However, it is also possible to use two Measurement Agents when 
performing one-way Measurement Tasks, as described in Figure 9. Both 
MAs are instructed by the Controller: MA-1 to send the traffic and 
MA-2 to measure the received traffic and send Reports to the 
Collector. Note that the Measurement Task at MA-2 can listen for 
traffic from MA-1 and respond multiple times without having to be 
rescheduled. 
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$ + AO + ĝi 
| | | | non-LMAP 
iperf -u sender |-UDP traffic->| iperf -u receiver Scope 
v 
AS td aus (mr enasés ie sas least a de 
| MA-1 | maza IA 
| LMAP interface | | LMAP interface | 
+---------------- + $------------------- + | 
Instruction | Instruction{Report} | | Report 
(Task, | Pes aR ES PR RR SAS E | | 
Schedule} | | | | 
| | v LMAP 
JAR F fo AS + Scope 
| Controller | Collector | 
$ + $ + v 


MA: Measurement Agent 


Figure 9: Schematic of LMAP-based Measurement System, with two 
Measurement Agents cooperating to measure UDP traffic 


Next, we consider Measurement Methods that meter the Observed Traffic 
Flow. Traffic generated in one point in the network is flowing 
towards a given destination and the traffic is observed in some point 
along the path. One way to implement this is that the endpoints 
generating and receiving the traffic are not instructed by the 
Controller; hence they are MPs. The MA is located along the path 
with a monitor function that measures the traffic. The MA is 
instructed by the Controller to monitor that particular traffic and 
to send the Report to the Collector. It is depicted in Figure 10. 
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+-------- + $ + Ho ===> + À 
|End user| | monitor | Observed |End user] 
qo SSeS ae SS ea as heer non-LMAP 
Flow Scope 
+-------- + | +-------- + | 
Po da des A of ect tna Rou h T ots tan 
<MP> |MA:LMAP interface | <MP> A 
$------------------ + | 
Instruction | Report 
| +----------------- + | 
| | 
| v LMAP 
TR AAA F E cea + Scope 
| Controller Collector 
do + $ + v 


MA: Measurement Agent 
MP: Measurement Peer 


Figure 10: LMAP deployment example, with a Measurement Agent 
monitoring traffic 


7. Security Considerations 


The security of the LMAP framework should protect the interests of 
the measurement operator (s), the network user(s), and other actors 
who could be impacted by a compromised measurement deployment. The 
Measurement System must secure the various components of the system 
from unauthorised access or corruption. Much of the general advice 
contained in Section 6 of [RFC4656] is applicable here. 


The process to upgrade the firmware in an MA is outside the scope of 
the initial LMAP work, just as is the protocol to Bootstrap the MAs. 
However, systems that provide remote upgrades must secure authorised 
access and integrity of the process. 


We assume that each Measurement Agent (MA) will receive its 
Instructions from a single organisation, which operates the 
Controller. These Instructions must be authenticated (to ensure that 
they come from the trusted Controller), checked for integrity (to 
ensure no one has tampered with them), and not vulnerable to replay 
attacks. If a malicious party can gain control of the MA, they can 
use it to launch denial-of-service (DoS) attacks at targets, create a 
platform for pervasive monitoring [RFC7258], reduce the end-user’s 
quality of experience, and corrupt the Measurement Results that are 
reported to the Collector. By altering the Measurement Tasks and/or 
the address that Results are reported to, they can also compromise 
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the confidentiality of the network user and the MA environment (such 
as information about the location of devices or their traffic). The 
Instruction Messages also need to be encrypted to maintain 
confidentiality, as the information might be useful to an attacker. 


Reporting by the MA must be encrypted to maintain confidentiality, so 
that only the authorised Collector can decrypt the results to prevent 
the leakage of confidential or private information. Reporting must 
also be authenticated (to ensure that it comes from a trusted MA and 
that the MA reports to a genuine Collector) and not vulnerable to 
tampering (which can be ensured through integrity and replay checks). 
It must not be possible to fool an MA into injecting falsified data 
and the results must also be held and processed securely after 
collection and analysis. See Section 8.5.2 for additional 
considerations on stored data compromise, and Section 8.6 on 
potential mitigations for compromise. 


Since Collectors will be contacted repeatedly by MAs using the Report 
Protocol to convey their recent results, a successful attack to 
exhaust the communication resources would prevent a critical 
operation: reporting. Therefore, all LMAP Collectors should 
implement technical mechanisms to: 


o limit the number of reporting connections from a single MA 
(simultaneous and established in some time period). 


o limit the transmission rate from a single MA. 
o limit the memory/storage consumed by a single MA's reports. 
o efficiently reject reporting connections from unknown sources. 


o separate resources if multiple authentication strengths are used, 
where the resources should be separated according to each class of 
strength. 


A corrupted MA could report falsified information to the Collector. 
Whether this can be effectively mitigated depends on the platform on 
which the MA is deployed. However, where the MA is deployed on a 
customer-controlled device, then the reported data is to some degree 
inherently untrustworthy. Further, a sophisticated party could 
distort some Measurement Methods, perhaps by dropping or delaying 
packets for example. This suggests that the network operator should 
be cautious about relying on Measurement Results for action such as 
refunding fees if a service level agreement is not met. 


As part of the protocol design, it will be decided how LMAP operates 
over the underlying protocol (Section 5.5). The choice raises 


Eardley, et al. Informational [Page 37] 


RFC 7594 LMAP Framework September 2015 


various security issues, such as how to operate through a NAT and how 
to protect the Controller and Collector from DoS attacks. 


The security mechanisms described above may not be strictly necessary 
if the network’s design ensures the LMAP components and their 
communications are already secured, for example potentially if they 
are all part of an ISP’s dedicated management network. 


Finally, there are three other issues related to security: privacy 
(considered in Section 8), availability, and "gaming the system". 
While the loss of some MAs may not be considered critical, the 
unavailability of the Collector could mean that valuable business 
data or data critical to a regulatory process is lost. Similarly, 
the unavailability of a Controller could mean that the MAs do not 
operate a correct Measurement Schedule. 


A malicious party could "game the system". For example, where a 
regulator is running a Measurement System in order to benchmark 
operators, an operator could try to identify the broadband lines that 
the regulator was measuring and prioritise that traffic. Normally, 
this potential issue is handled by a code of conduct. It is outside 
the scope of the initial LMAP work to consider the issue. 


8. Privacy Considerations 
The LMAP work considers privacy a core requirement and will ensure 


that by default the Control and Report Protocols operate ina 
privacy-sensitive manner and that privacy features are well defined. 


This section provides a set of privacy considerations for LMAP. This 
section benefits greatly from the publication of [RFC6973]. Privacy 
and security (Section 7) are related. In some jurisdictions, privacy 


is called data protection. 


We begin with a set of assumptions related to protecting the 
sensitive information of individuals and organisations participating 
in LMAP-orchestrated measurement and data collection. 


8.1. Categories of Entities with Information of Interest 


LMAP protocols need to protect the sensitive information of the 
following entities, including individuals and organisations who 
participate in measurement and collection of results. 


o Individual Internet users: Persons who utilise Internet access 


services for communications tasks, according to the terms of 
service of a service agreement. Such persons may be a service 
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Subscriber, or have been given permission by the Subscriber to use 
the service. 


o Internet service providers: Organisations that offer Internet 
access service subscriptions, and thus have access to sensitive 
information of individuals who choose to use the service. These 
organisations desire to protect their Subscribers and their own 
sensitive information, which may be stored in the process of 
performing Measurement Tasks and collecting Results. 


o Regulators: Public authorities responsible for exercising 
supervision of the electronic communications sector, and which may 
have access to sensitive information of individuals who 


participate in a measurement campaign. Similarly, regulators 
desire to protect the participants and their own sensitive 
information. 


o Other LMAP system operators: Organisations who operate Measurement 
Systems or participate in measurements in some way. 


Although privacy is a protection extended to individuals, we discuss 
data protection by ISPs and other LMAP system operators in this 
section. These organisations have sensitive information involved in 
the LMAP system, and many of the same dangers and mitigations are 
applicable. Further, the ISPs store information on their Subscribers 
beyond that used in the LMAP system (for example, billing 
information), and there should be a benefit in considering all the 
needs and potential solutions coherently. 


8.2. Examples of Sensitive Information 
This section gives examples of sensitive information that may be 
measured or stored in a Measurement System, and that is to be kept 


private by default in the LMAP core protocols. 


Examples of Subscriber or authorised Internet user sensitive 
information: 


o Sub-IP-layer addresses and names (MAC address, base station ID, 
SSID) 


o IP address in use 
o Personal Identification (real name) 
o Location (street address, city) 


o Subscribed service parameters 
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o Contents of traffic (activity, DNS queries, destinations, 
equipment types, account info for other services, etc.) 


o Status as a study volunteer and Schedule of Measurement Tasks 
Examples of Internet Service Provider sensitive information: 

o Measurement device identification (equipment ID and IP address) 
o Measurement Instructions (choice of measurements) 

o Measurement Results (some may be shared, others may be private) 


o Measurement Schedule (exact times) 


o Network topology (locations, connectivity, redundancy) 


o Subscriber billing information, and any of the above Subscriber 
information known to the provider. 


o Authentication credentials (such as certificates) 


Other organisations will have some combination of the lists above. 
The LMAP system would not typically expose all of the information 
above, but could expose a combination of items that could be 
correlated with other pieces collected by an attacker (as discussed 
in Section 8.5 on Threats). 


8.3. Different Privacy Issues Raised by Different Sorts of Measurement 
Methods 


Measurement Methods raise different privacy issues depending on 
whether they measure traffic created specifically for that purpose or 
whether they measure user traffic. 


Measurement Tasks conducted on user traffic store sensitive 
information, however briefly this storage may be. We note that some 
authorities make a distinction on time of storage, and information 
that is kept only temporarily to perform a communications function is 
not subject to regulation (for example, active queue management, deep 
packet inspection). Such Measurement Tasks could reveal all the 
websites a Subscriber visits and the applications and/or services 
they use. This issue is not specific to LMAP. For instance, IPFIX 
has discussed similar issues (see Section 11.8 of [RFC7011]), but 
mitigations described in the sections below were considered beyond 
their scope. 
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In contrast to Measurement Tasks conducted on user traffic, other 
Measurement Tasks use traffic which is created specifically for the 
purpose of measurement. Even if a user host generates Measurement 
Traffic, there is limited sensitive information about the Subscriber 
present and stored in the Measurement System: 


o IP address in use (and possibly sub-IP addresses and names) 
o Status as a study volunteer and Schedule of Measurement Tasks 


On the other hand, for a service provider, the sensitive information 
like Measurement Results is the same for all Measurement Tasks. 


From the Subscriber perspective, both types of Measurement Tasks 
potentially expose the description of Internet access service and 
specific service parameters, such as the Subscriber rate and type of 
access. 


8.4. Privacy Analysis of the Communication Models 


This section examines each of the protocol exchanges described at a 
high level in Section 5 and some example Measurement Tasks, and it 
identifies specific sensitive information that must be secured during 
communication for each case. With the protocol-related sensitive 
information identified, we can better consider the threats described 
in the following section. 


From the privacy perspective, all entities participating in LMAP 
protocols can be considered "observers" according to the definition 
in [RFC6973]. Their stored information potentially poses a threat to 
privacy, especially if one or more of these functional entities has 
been compromised. Likewise, all devices on the paths used for 
control, reporting, and measurement are also observers. 


8.4.1. MA Bootstrapping 


Section 5.1 provides the communication model for the Bootstrapping 
process. 


Although the specification of mechanisms for Bootstrapping the MA are 
beyond the scope of the initial LMAP work, designers should recognise 
that the Bootstrapping process is extremely powerful and could cause 
an MA to join a new or different LMAP system with a different 
Controller and Collector, or simply install new Metrics with 
associated Measurement Methods (for example, to record DNS queries). 
A Bootstrap attack could result in a breach of the LMAP system with 
significant sensitive information exposure depending on the 
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warranted. 


The Bootstrapping process provides sensitive information about the 
LMAP system and the organisation that operates it, such as 


o the MA’s identifier (MA-ID) 


o the address that identifies the Control Channel, such as the 
Controller’s FQDN 


o Security information for the Control Channel 


During the Bootstrap process for an MA located at a single 
Subscriber’s service demarcation point, the MA receives an MA-ID, 
which is a persistent pseudonym for the Subscriber. Thus, the MA-ID 
is considered sensitive information because it could provide the link 
between Subscriber identification and Measurements Results. 


Also, the Bootstrap process could assign a Group-ID to the MA. The 
specific definition of information represented in a Group-ID is to be 
determined, but several examples are envisaged including use as a 
pseudonym for a set of Subscribers, a class of service, an access 
technology, or other important categories. Assignment of a Group-ID 
enables anonymisation sets to be formed on the basis of service 
type/grade/rates. Thus, the mapping between Group-ID and MA-ID is 
considered sensitive information. 


8.4.2. Controller <-> Measurement Agent 


The high-level communication model for interactions between the LMAP 
Controller and Measurement Agent is illustrated in Section 5.2. The 
primary purpose of this exchange is to authenticate and task a 
Measurement Agent with Measurement Instructions, which the 
Measurement Agent then acts on autonomously. 


Primarily, IP addresses and pseudonyms (MA-ID, Group-ID) are 
exchanged with a capability request, then measurement-related 
information of interest such as the parameters, schedule, metrics, 
and IP addresses of measurement devices. Thus, the measurement 
Instruction contains sensitive information that must be secured. For 
example, the fact that an ISP is running additional measurements 
beyond the set reported externally is sensitive information, as are 
the additional Measurements Tasks themselves. The Measurement 
Schedule is also sensitive, because an attacker intending to bias the 
results without being detected can use this information to great 
advantage. 
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An organisation operating the Controller having no service 
relationship with a user who hosts the Measurement Agent *could* gain 
real-name mapping to a public IP address through user participation 
in an LMAP system (this applies to the Measurement Collection 
protocol, as well). 


8.4.3. Collector <-> Measurement Agent 


The high-level communication model for interactions between the 
Measurement Agent and Collector is illustrated in Section 5.4. The 
primary purpose of this exchange is to authenticate and collect 
Measurement Results from an MA, which the MA has measured 
autonomously and stored. 


The Measurement Results are the additional sensitive information 
included in the Collector-MA exchange. Organisations collecting LMAP 


measurements have responsibility for data control. Thus, the Results 
and other information communicated in the Collector protocol must be 
secured. 


8.4.4. Measurement Peer <-> Measurement Agent 


A Measurement Method involving Measurement Traffic raises potential 
privacy issues, although the specification of the mechanisms is 
beyond the scope of the initial LMAP work. The high-level 
communications model below illustrates the various exchanges to 
execute such a Measurement Method and store the Results. 


We note the potential for additional observers in the figures below 
by indicating the possible presence of a NAT, which has additional 


significance to the protocols and direction of initiation. 


The various messages are optional, depending on the nature of the 


Measurement Method. It may involve sending Measurement Traffic from 
the Measurement Peer to MA, MA to Measurement Peer, or both. 
Similarly, a second (or more) MAs may be involved. (Note: For 


simplicity, Figure 11 and the description don’t show the non-LMAP 
functionality that is associated with the transfer of the Measurement 
Traffic and is located at the devices with the MA and MP.) 
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Measurement Peer |=========== NAT ? ========== Measurement Agent 
<- (Key Negotiation & 
Encryption Setup) 
(Encrypted Channel => 
Established) 
(Announce capabilities -> 
& status) 
<- (Select capabilities) 
ACK => 
<- (Measurement Request 
(MA+MP IPAddrs,set of 
Metrics, Schedule)) 
ACK RA 
Measurement Traffic <> Measurement Traffic 
(may/may not be encrypted) (may/may not be encrypted) 
<- (Stop Measurement Task) 
Measurement Results => 


(if applicable) 
<- ACK, Close 


Figure 11: Interactions between Measurement Peer and Measurement 
Agent 


This exchange primarily exposes the IP addresses of measurement 
devices and the inference of measurement participation from such 
traffic. There may be sensitive information on key points in a 
service provider’s network included. There may also be access to 
measurement-related information of interest such as the Metrics, 
Schedule, and intermediate results carried in the Measurement Traffic 
(usually a set of timestamps). 


The Measurement Peer may be able to use traffic analysis (perhaps 
combined with traffic injection) to obtain interesting insights about 
the Subscriber. As a simple example, if the Measurement Task 
includes a pre-check that the end user isn’t already sending traffic, 
the Measurement Peer may be able to deduce when the Subscriber is 
away on holiday. 


If the Measurement Traffic is unencrypted, as found in many systems 


today, then both timing and limited results are open to on-path 
observers. 
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8.4.5. Measurement Agent 


Some Measurement Methods only involve a single Measurement Agent 
observing existing traffic. They raise potential privacy issues, 
although the specification of the mechanisms is beyond the scope of 
the initial LMAP work. 


The high-level communications model shown in Figure 12 illustrates 
the collection of user information of interest with the Measurement 


Agent performing the monitoring and storage of the Results. This 
particular exchange is for measurement of DNS Response Time, which 
most frequently uses UDP transport. (Note: For simplicity, Figure 12 


and its description do not show the non-LMAP functionality that is 
associated with the transfer (export) of the observed Measurement 
Traffic beyond the measurement devices located with the MA.) 


| DNS Server |=========== NAT ? * | User client | 
| | ^ | | 
| 
Measurement 
| Agent | 
| | 
<- Name Resolution Required 


(MA+MP IPAddrs, 
Desired Domain Name) 
Return Record => 


MA: Measurement Agent 
MP: Measurement Peer 


Figure 12: LMAP deployment example, with Measurement Agent monitoring 
DNS response time 


In this particular example, the MA monitors DNS messages in order to 


measure the DNS response time. The Measurement Agent may be embedded 
in the user host, or it may be located in another device capable of 
observing user traffic. The MA learns the IP addresses of 


measurement devices and the intent to communicate with or access the 
services of a particular domain name, and perhaps also information on 
key points in a service provider’s network, such as the address of 
one of its DNS servers. 
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In principle, any of the user sensitive information of interest 
(listed above) can be collected and stored in the monitoring scenario 
and so must be secured. 


It would also be possible for a Measurement Agent to source the DNS 
query itself, and then there are not many privacy concerns. 


8.4.6. Storage and Reporting of Measurement Results 


Although the mechanisms for communicating results (beyond the initial 
Collector) are beyond the scope of the initial LMAP work, there are 
potential privacy issues related to a single organisation’s storage 
and reporting of Measurement Results. Both storage and reporting 
functions can help to preserve privacy by implementing the 
mitigations described below. 


8.5. Threats 


This section indicates how each of the threats described in [RFC6973] 
apply to the LMAP entities and their communication and storage of 
"information of interest". DoS and other attacks described in the 
Security section represent threats as well, and these attacks are 
more effective when sensitive information protections have been 
compromised. 


8.5.1. Surveillance 


Section 5.1.1 of [RFC6973] describes surveillance as the "observation 
or monitoring of an individual’s communications or activities." 
Hence, all Measurement Methods that measure user traffic are a form 
of surveillance, with inherent risks. 


Measurement Methods that avoid periods of user transmission 
indirectly produce a record of times when a subscriber or authorised 
user has used their network access service. 


Measurement Methods may also utilise and store a Subscriber’s 
currently assigned IP address when conducting measurements that are 
relevant to a specific Subscriber. Since the Measurement Results are 
timestamped, they could provide a record of IP address assignments 
over time. 


Either of the above pieces of information could be useful in 
correlation and identification, as described below. 
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-2. Stored Data Compromise 


Section 5.1.2 of [RFC6973] describes Stored Data Compromise as 
resulting from inadequate measures to secure stored data from 
unauthorised or inappropriate access. For LMAP systems, this 
includes deleting or modifying collected measurement records, as well 
as data theft. 


The primary LMAP entity subject to compromise is the repository, 
which stores the Measurement Results; extensive security and privacy 
threat mitigations are warranted. The Collector and MA also store 
sensitive information temporarily and need protection. The 
communications between the local storage of the Collector and the 
repository is beyond the scope of the initial LMAP work, though this 
communications channel will certainly need protection as will the 
mass storage itself. 


The LMAP Controller may have direct access to storage of Subscriber 
information (for example, location, billing, service parameters, 
etc.) and other information that the controlling organisation 
considers private and again needs protection. 


Note that there is tension between the desire to store all raw 
results in the LMAP Collector (for reproduction and custom analysis) 
and the need to protect the privacy of measurement participants. 
Many of the mitigations described in Section 8.6 are most efficient 
when deployed at the MA, therefore minimising the risks associated 
with stored results. 


.3. Correlation and Identification 


Sections 5.2.1 and 5.2.2 of [RFC6973] describe correlation as 
combining various pieces of information to obtain desired 
characteristics of an individual, and identification as using this 
combination to infer identity. 


The main risk is that the LMAP system could unwittingly provide a key 
piece of the correlation chain, starting with an unknown Subscriber's 
IP address and another piece of information. For example, a 
Subscriber utilised Internet access from 2000 to 2310 UTC, because 
the Measurement Tasks were deferred or sent a name resolution for 
www.example.com at 2300 UTC. 


If a user's access with another system already gave away sensitive 
information, correlation is clearly easier and can result in 
re-identification, even when an LMAP system conserves sensitive 
information to great extent. 
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8.5.4. Secondary Use and Disclosure 


Sections 5.2.3 and 5.2.4 of [RFC6973] describe secondary use as 
unauthorised utilisation of an individual’s information for a purpose 
the individual did not intend, and disclosure as when such 
information is revealed causing another’s notions of the individual 
to change or confidentiality to be violated. 


Measurement Methods that measure user traffic are a form of secondary 
use, and the Subscribers’ permission should be obtained beforehand. 
It may be necessary to obtain the measured ISP’s permission to 
conduct measurements (for example, when required by the terms and 
conditions of the service agreement) and notification is considered 
good measurement practice. 


For Measurement Methods that measure Measurement Traffic the 
Measurement Results provide some limited information about the 
Subscriber or ISP and could result in secondary uses. For example, 
the use of the Results in unauthorised marketing campaigns would 
qualify as secondary use. Secondary use may break national laws and 
regulations, and may violate an individual’s expectations or desires. 


8.6. Mitigations 


This section examines the mitigations listed in Section 6 of 
[RFC6973] and their applicability to LMAP systems. Note that each 
section in [RFC6973] identifies the threat categories that each 
technique mitigates. 


8.6.1. Data Minimisation 


Section 6.1 of [RFC6973] encourages collecting and storing the 
minimal information needed to perform a task. 


LMAP Results can be useful for general reporting about performance 
and for specific troubleshooting. They need different levels of 
information detail, as explained in the paragraphs below. 


For general reporting, the results can be aggregated into large 
categories (for example, the month of March, all US subscribers West 
of the Mississippi River). In this case, all individual 
identifications (including IP address of the MA) can be excluded, and 
only relevant results are provided. However, this implies a 
filtering process to reduce the information fields, because greater 
detail was needed to conduct the Measurement Tasks in the first 
place. 
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For troubleshooting, so that a network operator or end user can 
identify a performance issue or failure, potentially all the network 
information (for example, IP addresses, equipment IDs, location), 
Measurement Schedules, service configurations, Measurement Results, 
and other information may assist in the process. This includes the 
information needed to conduct the Measurements Tasks, and represents 
a need where the maximum relevant information is desirable; 
therefore, the greatest protections should be applied. This level of 
detail is greater than needed for general performance monitoring. 


As regards Measurement Methods that measure user traffic, we note 
that a user may give temporary permission (to enable detailed 
troubleshooting), but withhold permission for them in general. Here 
the greatest breadth of sensitive information is potentially exposed, 
and the maximum privacy protection must be provided. The Collector 
may perform pre-storage minimisation and other mitigations 

(Section 8.6.4) to help preserve privacy. 


For MAs with access to the sensitive information of users (for 
example, within a home or a personal host/handset), it is desirable 
for the Results collection to minimise the data reported, but also to 
balance this desire with the needs of troubleshooting when a service 
subscription exists between the user and organisation operating the 
measurements. 


8.6.2. Anonymity 


Section 6.1.1 of [RFC6973] describes an "anonymity set" as a way in 
which anonymity is achieved: "there must exist a set of individuals 
that appear to have the same attribute(s) as the individual." 


Experimental methods for anonymisation of user-identifiable data (and 
so particularly applicable to Measurement Methods that measure user 
traffic) have been identified in [RFC6235]. However, the findings of 
several of the same authors is that "there is increasing evidence 
that anonymization applied to network trace or flow data on its own 
is insufficient for many data protection applications as in [Burl0]." 
Essentially, the details of such Measurement Methods can only be 
accessed by closed organisations, and unknown injection attacks are 
always less expensive than the protections from them. However, some 
forms of summary may protect the user’s sensitive information 
sufficiently well, and so each Metric must be evaluated in the light 
of privacy. 


The techniques in [RFC6235] could be applied more successfully in 
Measurement Methods that generate Measurement Traffic, where there 
are protections from injection attack. The successful attack would 
require breaking the integrity protection of the LMAP Reporting 
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Protocol and injecting Measurement Results (known fingerprint, see 
Section 3.2 of [RFC6973]) for inclusion with the shared and 
anonymised results, then fingerprinting those records to ascertain 
the anonymisation process. 


Beside anonymisation of measured Results for a specific user or 
provider, the value of sensitive information can be further diluted 
by summarising the Results over many individuals or areas served by 
the provider. There is an opportunity enabled by forming anonymity 
sets [RFC6973] based on the reference path measurement points in 
[RFC7398]. For example, all measurements from a Subscriber device 
can be identified as "mp000", instead of using the IP address or 
other device information. The same anonymisation applies to the 
Internet Service Provider, where their Internet gateway would be 
referred to as "mp190". 


Another anonymisation technique is for the MA to include its Group-ID 
instead of its MA-ID in its Measurement Reports, with several MAs 
sharing the same Group-ID. 


8.6.3. Pseudonymity 


Section 6.1.2 of [RFC6973] indicates that pseudonyms, or nicknames, 
are a possible mitigation to revealing one’s true identity, since 
there is no requirement to use real names in almost all protocols. 


A pseudonym for a measurement device’s IP address could be an 
LMAP-unique equipment ID. However, this would likely be a permanent 
handle for the device, and long-term use weakens a pseudonym’s power 
to obscure identity. 


8.6.4. Other Mitigations 


Data can be depersonalised by blurring it, for example by adding 
synthetic data, data-swapping, or perturbing the values in ways that 
can be reversed or corrected. 


Sections 6.2 and 6.3 of [RFC6973] describe user participation and 
security, respectively. 


Where LMAP measurements involve devices on the subscriber’s premises 
or Subscriber-owned equipment, it is essential to secure the 
Subscriber’s permission with regard to the specific information that 
will be collected. The informed consent of the Subscriber (and, if 
different, the end user) may be needed, including the specific 
purpose of the measurements. The approval process could involve 
showing the Subscriber their measured information and results before 
instituting periodic collection, or before all instances of 
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9. 


collection, with the option to cancel collection temporarily or 
permanently. 


It should also be clear who is legally responsible for data 
protection (privacy); in some jurisdictions, this role is called the 
‘data controller’. It is always good practice to limit the time that 
personal information is stored. 


Although the details of verification would be impenetrable to most 
subscribers, the MA could be architected as an "app" with open source 
code, pre-download and embedded terms of use and agreement on 
measurements, and protection from code modifications usually provided 
by the app stores. Further, the app itself could provide data 
reduction and temporary storage mitigations as appropriate and 
certified through code review. 


LMAP protocols, devices, and the information they store clearly need 
to be secure from unauthorised access. This is the hand-off between 
privacy and security considerations (Section 7). The data controller 
is responsible (legally) for maintaining data protections described 
in the Subscriber’s agreement and agreements with other 
organisations. 


Finally, it is recommended that each entity described in Section 8.1, 
(for example, individuals, ISPs, regulators, others) assess the risks 
of LMAP data collection by conducting audits of their data protection 
methods. 
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